7.1.1 CMSCardRequest/Parameters

Contains the settings for the import. See section 5, Advanced settings.

7.1.2 CMSCardRequest/Group

Contains details of the Group to which the user will belong. If the group does not exist, MyID can create the group, depending on your Parameters settings.

Note: A group created through the Lifecycle API does not inherit any default roles from its parent group, and you cannot set default roles through the Lifecycle API. This means that for any new users created within this new group, you must specify all of the roles that you want to assign; if you do not specify any roles, the user receives the default Cardholder and Password User roles.

7.1.3 CMSCardRequest/Group/Name

Used to identify the group. Mandatory.

If you are specifying an existing group, this is the only element you need to include to identify the group. If you are specifying a new group, you can complete the rest of the elements to provide the details for the new group.

Note: Group names must be unique. The import will fail if two different groups have the same name as the specified group name.

Note: If you specify a group that has been linked to an LDAP OU in MyID, any users associated with the group will be synchronized with the directory if the PushToLDAP parameter is set to 1.

7.1.4 CMSCardRequest/Group/Description

The description of the group.

7.1.5 CMSCardRequest/Group/OrgUnit

The OU of the group.

7.1.6 CMSCardRequest/Group/Parent

The parent of the group.

Used for new groups only. This is the name of the group beneath which the specified group will be created. For new groups, if you do not specify a parent group, the new group is placed under the root.

Note: Parent group names must be unique. The import will fail if two different groups have the same name as the specified parent name.

7.1.7 CMSCardRequest/Group/AdditionalFields

Contains any extended group (Xg) fields. See section 3.8, Importing additional fields or details.

7.1.8 CMSCardRequest/Group/User

Contains the details for the user for whom the card is being requested.

You can import a single user in each XML document.

Note: You do not have to include a User node if you are importing the details of a group.

7.1.9 CMSCardRequest/Group/User/Personal

Contains the user's personal details. Mandatory.

7.1.10 CMSCardRequest/Group/User/Personal/FirstName

Internal name: FirstName

The user's first name.

7.1.11 CMSCardRequest/Group/User/Personal/LastName

Internal name: Surname

The user's last name.

Note: You must include one or both of FirstName and LastName. If you include both FirstName and LastName, make sure you specify them in that order – FirstName first, LastName immediately after. If you intend to supply only a FirstName or only a LastName, omit the other node – do not simply include an empty string.

7.1.12 CMSCardRequest/Group/User/Personal/Initial

Internal name: Initial

The user's middle initials.

7.1.13 CMSCardRequest/Group/User/Personal/Title

Internal name: Title

The user's title.

7.1.14 CMSCardRequest/Group/User/Personal/Email

Internal name: Email

The user's email address. This address is used for email notifications.

7.1.15 CMSCardRequest/Group/User/Personal/PhoneExt

Internal name: PhoneExt

The user's phone extension.

7.1.16 CMSCardRequest/Group/User/Personal/MobileNumber

Internal name: MobileNumber

The user's mobile phone number.

7.1.17 CMSCardRequest/Group/User/Personal/PhoneNumber

Internal name: PhoneNumber

The user's phone number.

7.1.18 CMSCardRequest/Group/User/Personal/EmployeeID

Internal name: EmployeeID

This should be a unique identifier for the applicant.

7.1.19 CMSCardRequest/Group/User/Personal/OptionalLine1

Internal name: OptionalLine1

Used to store extra information about the user.

7.1.20 CMSCardRequest/Group/User/Personal/OptionalLine2

Internal name: OptionalLine2

Used to store extra information about the user.

7.1.21 CMSCardRequest/Group/User/Personal/OptionalLine3

Internal name: OptionalLine3

Used to store extra information about the user.

7.1.22 CMSCardRequest/Group/User/Personal/OptionalLine4

Internal name: OptionalLine4

Used to store extra information about the user.

7.1.23 CMSCardRequest/Group/User/Authentication

Contains details of the security phrases to be used for the user.

Note: Currently, the schema does not provide validation on the Authentication element.

7.1.24 CMSCardRequest/Group/User/Authentication/SecurityPhrase

Contains a pair of elements – a Prompt and an Answer – that provide a security phrase for the applicant.

You can have up to five SecurityPhrase elements, each containing a Prompt and Answer pair.

Note: If you provide any security phrases for an existing user, all existing security phrases on that user's account are removed and replaced with the newly-provided security phrases. You can use this feature to delete the security phrases from a user's account – provide a single Prompt with an empty Answer, and the user's security phrases will be removed. (If the minimum number of security phrases is set to 1, the user will still be prompted for a security phrase when attempting to log on, but will be unable to authenticate.)

7.1.25 CMSCardRequest/Group/User/Authentication/SecurityPhrase/Prompt

Internal name: Question field in SecurityQuestions

Used to import a security question. If the question does not already exist, an entry is added to the SecurityQuestions table; this question will subsequently be available for use when setting security phrases in MyID.

The default security questions are:

7.1.26 CMSCardRequest/Group/User/Authentication/SecurityPhrase/Answer

Internal name: SecurityPhrase field in UsersSecurityQuestions

Used to import an answer to a security question for an applicant. A hash of the answer is stored in the UsersSecurityQuestions table.

Important: Do not include any leading or trailing spaces in the security phrase answer. If you do include leading or trailing spaces, the user will be unable to authenticate to MyID.

Note: If you have set up the Security Phrase Complexity option within MyID to determine the complexity of security phrases, this is not enforced on any passwords that you import using the Lifecycle API.

You can encrypt the answer using a transport key – this allows you to maintain the security of the security phrase answer when you include it in the XML data.

To encrypt the answer:

1. Import your AES128 transport key into MyID using the Key Manager workflow.

2. External to MyID, encrypt the security phrase answer with the following settings:

   • Encode the security phrase answer as little-endian Unicode. Do not use a byte order mark.

     For example, a security phrase of answer would be encoded as:

     0061006E0073007700650072

   • Pad the data using ISO9797 Method 2 (pad with a single 0x80, then 0x00 until the block-length is reached).

   • Encrypt using CBC or ECB mode encryption.

3. Add the hex-encoded encrypted data to the Answer node.

4. Set the KeyName attribute of the Answer node to the name of the transport key you imported into MyID.

5. Set the Mode attribute of the Answer node to either CBC or ECB, depending on how you encrypted the answer.

For example:

• The transport key, MyTransportKey, has a value of:

  206890FC9B4EA1D0137D8C692B3BFCB6

• The security phrase is:

  answer

• In the import, use the following:

  <Answer KeyName="MyTransportKey" Mode="CBC">6713987B589F76BC4DA0F557D79A6275</Answer>

If you do not want to encrypt the answer in the XML document, omit the KeyName and Mode attributes. For example:

<Answer>plaintextanswer1234</Answer>

7.1.27 CMSCardRequest/Group/User/Card

Contains details of the card to be requested for the user.

7.1.28 CMSCardRequest/Group/User/Card/CardProfile

If present, this will request a card using the specified credential profile for this applicant. If performing an update, or the credential profile does not exist, no request will be made.

Note: Credential profiles were previously known as card profiles.

7.1.29 CMSCardRequest/Group/User/Card/CardExpiryDate

Used to specify the expiry date for the card when it is issued. The card will expire on the date specified, or on the date the credential profile specifies, whichever is earlier.

The format is YYYY-MM-DD – for example, 2016-12-25.

Note: If the Expire Cards at End of Day configuration option is set to Yes, the time portion of the card expiry date is set to 23:59 UTC – the end of the day. If the Expire Cards at End of Day option is set to No, the time portion is set to the time of the import. However, if the Expire Cards at End of Day option is set to No, and the card expiry date is constrained by an earlier card lifetime as configured in the credential profile, the time portion is set to 00:00 UTC – the start of the day.

Note: Some CAs do not allow control over the time portion of the certificate expiry. When MyID sets the lifetime of the certificate, the date is set as expected, but the time may not match exactly, depending on the certificate authority being used.

If you provide a date in the CardExpiryDate node, and this exceeds the Maximum Expiry Date set against the user account, the CardExpiryDate is ignored, and the Maximum Expiry Date is used in the request. This may be changed at the time of collection to an earlier date, if the lifetime configured in the credential profile limits it.

7.1.30 CMSCardRequest/Group/User/Card/Renewal

Used to specify whether the card is a renewal of an existing card. If the user already exists, you must set this option to true or card request jobs will not be created.

Can be one of the following values:

• true – this is a card renewal.

• false – this is not a card renewal.

Note: For card renewals, you must specify the card's original serial number and device type using the CMSCardRequest/Group/User/Card/Update node.

7.1.31 CMSCardRequest/Group/User/Card/ImportCard

Used to specify whether to import a device (see section 3.11, Importing operator credentials).

Can be one of the following values:

• true – import a device.

• false – do not import a device.

7.1.32 CMSCardRequest/Group/User/Card/CardRequestedBy

This is the logon name of the person requesting the card. Used for auditing purposes.

7.1.33 CMSCardRequest/Group/User/Card/CancelExisting

Used to specify whether existing jobs of the same type are canceled when the new job is created. Include the empty node if you want to cancel the existing jobs:

<CancelExisting/>

If you omit this node, existing jobs will not be canceled when the new job is created.

7.1.34 CMSCardRequest/Group/User/Card/JobLabel

Used to specify a label for the job. You can use this label to search for and identify the job within MyID.

7.1.35 CMSCardRequest/Group/User/Card/Update

Used to specify the card being updated or renewed. You must make sure that the card is issued to the user.

For updates, if you do not specify the OriginalSerialNumber and OriginalDeviceType for the card to be updated, the card currently assigned to the user is used.

For renewals, the OriginalSerialNumber and OriginalDeviceType for the card to be renewed are mandatory.

7.1.36 CMSCardRequest/Group/User/Card/Update/OriginalSerialNumber

The serial number of the card being updated or renewed. Used to target a specific card.

7.1.37 CMSCardRequest/Group/User/Card/Update/OriginalDeviceType

The device type of the card being updated or renewed.

7.1.38 CMSCardRequest/Group/User/Card/Update/StatusMapping

The status mapping code to be used when the card is updated.

See section 3.7.5, Status mapping codes.

7.1.39 CMSCardRequest/Group/User/Card/Update/ParametersXML

Contains parameters for the card update job.

7.1.40 CMSCardRequest/Group/User/Card/Update/ParametersXML/UnlockPIN

Not supported.

7.1.41 CMSCardRequest/Group/User/Card/Update/ParametersXML/ReIssue

Set to 1 to request the reissuance of a device.

Reissuance is a type of card update job that, when collected, carries out the following:

• Revokes existing certificates present on the device.

• Re-applies data model electronic personalization.

• Issues and writes a new set of certificates onto the device (according to the credential profile).

• If the Rotate Keys On Card Update configuration option is set (on the Issuance Processes page of the Operation Settings workflow) applies the latest customer GlobalPlatform and PIV 9B keys.

7.1.42 CMSCardRequest/Group/User/Card/Replacement

Used to specify the card to be replaced.

Note: The Card Renewal Period configuration option (on the Devices page of the Operation Settings workflow) is ignored when requesting replacement cards through the Lifecycle API – it is possible to request short-lived replacement credentials through the API.

7.1.43 CMSCardRequest/Group/User/Card/Replacement/OriginalSerialNumber

The serial number of the card to be replaced. Mandatory if you specify the Replacement node.

7.1.44 CMSCardRequest/Group/User/Card/Replacement/OriginalDeviceType

The device type of the card to be replaced. Mandatory if you specify the Replacement node.

7.1.45 CMSCardRequest/Group/User/Card/Replacement/StatusMapping

Used to specify the status mapping ID for certificates on the credentials that are being replaced. This node is used when performing a replacement request; note that if you are performing a card replacement, you use CMSCardRequest/Group/User/Card/StatusMapping instead.

If you do not specify a StatusMapping, a status mapping ID of 1 – Lost – is used.

See section 3.7.5, Status mapping codes.

7.1.46 CMSCardRequest/Group/User/Card/GenerateOTP

Note: This feature reserved for future use. It is not currently possible to use OTPs when collecting jobs. Do not use in the current version of MyID.

Used to generate a One-Time Password (OTP) for use when collecting the job created by the import request. If you specify this element, the user must provide the OTP when collecting the job. You can specify a notification mechanism to provide this OTP to the user by including a Notification node.

If you do not specify a Notification node, the OTP is sent to the user's email address using the Job OTP email template.

7.1.47 CMSCardRequest/Group/User/Card/GenerateOTP/Notification

Used to specify a notification method for OTPs.

7.1.48 CMSCardRequest/Group/User/Card/GenerateOTP/Notification/Name

The Name of the notification from the Notifications table in the MyID database.

Note: You must have notifications configured correctly within MyID. For more information, contact Intercede professional services.

7.1.49 CMSCardRequest/Group/User/Card/GenerateOTP/Notification/Action

Contains one of the following:

• Event – the notification is triggered once using the success data set up in the Notifications table. No further notifications are sent, even if the notification fails.

• Success – the notification is triggered using the success data set up in the Notifications table. If the notification fails, the back-up notifications set up in the fail data in the Notifications table are triggered.

• Fail – the notification is triggered using the fail data set up in the Notifications table. Multiple notifications are sent on a schedule specified by the RetryDelays in the Notifications table. You can use this option to force reminder notifications; the notification has not failed, but it is treated as a failed notification so that the retry system is triggered.

7.1.50 CMSCardRequest/Group/User/Card/OriginalSerialNumber

Used in conjunction with the CMSCardRequest/Group/User/Card/OriginalDeviceType node to specify a credential to be replaced. These settings also specify the credential profile to use when replacing the card. The credential profile used to issue this specified card is used to issue the new card. Alternatively, you can specify the credential profile using the CMSCardRequest/Group/User/Card/CardProfile node.

In addition, if you specify the OriginalSerialNumber and OriginalDeviceType for the card, all credentials on the same physical credential are marked as being replaced.

The CMSCardRequest/Group/User/Card/StatusMapping determines what happens to the certificates on the credentials that are being replaced.

7.1.51 CMSCardRequest/Group/User/Card/OriginalDeviceType

Used in conjunction with the CMSCardRequest/Group/User/Card/OriginalSerialNumber node to specify a credential to be replaced.

7.1.52 CMSCardRequest/Group/User/Card/SerialNumber

Used in conjunction with the CMSCardRequest/Group/User/Card/DeviceType node to specify an exact card to be issued.

7.1.53 CMSCardRequest/Group/User/Card/DeviceType

Used in conjunction with the CMSCardRequest/Group/User/Card/SerialNumber node to specify an exact card to be issued.

7.1.54 CMSCardRequest/Group/User/Card/StatusMapping

Used to specify the status mapping ID for certificates on the credentials that are being replaced. This node is used when performing a card request; note that if you are performing a card replacement, you use CMSCardRequest/Group/User/Card/Replacement/StatusMapping instead.

If you do not specify a StatusMapping, a status mapping ID of 1 – Lost – is used.

See section 3.7.5, Status mapping codes.

7.1.55 CMSCardRequest/Group/User/Card/RevocationComment

A free text description that is stored against revoked certificates in the database.

7.1.56 CMSCardRequest/Group/User/Card/Reprovision

Set the value of this node to 1 to request a reprovision rather than an update.

A reprovision allows you to re-encode a card completely, based on the data in the MyID database, using the latest version of the credential profile used during issuance.

The card will have the same expiry date as the original card. New certificates may have longer expiration times than the original certificates, but these will not exceed the lifetime of the card itself. Certificates that were revoked externally to MyID will be replaced with new active certificates.

When requesting a reprovision, specify a status mapping with one of the following values:

• 83 – User details have changed.

• 84 – There is a problem with the device.

• 85 – New credential profile needs to be applied.

Note: If you specify any other status mapping, it is ignored – only these status mappings carry out reprovisions.

For example:

<Card>
  <CardProfile>Yubikey NoOTP</CardProfile>
  <CardRequestedBy>System</CardRequestedBy> 
  <OriginalSerialNumber>8115516</OriginalSerialNumber>
  <OriginalDeviceType>YubiKey 4</OriginalDeviceType>
  <StatusMapping>84</StatusMapping>
  <Reprovision>1</Reprovision>
</Card>

7.1.57 CMSCardRequest/Group/User/Card/CardLayout

Optionally, contains the name of the card layout to use when printing the requested card.

The card layout name must be valid for the card's credential profile at the point that the card is issued; if the card layout name is not valid, the request will not be processed.

7.1.58 CMSCardRequest/Group/User/Card/Container

Used in conjunction with the CMSCardRequest/Group/User/Card/ImportCard node to specify the container that the authentication certificate is located in.

See section 3.11, Importing operator credentials.

7.1.59 CMSCardRequest/Group/User/Card/Certificate

Used in conjunction with the CMSCardRequest/Group/User/Card/ImportCard node to specify the authentication certificate on the imported card. This must be the base64 representation of the certificate without headers, footers, or line breaks.

See section 3.11, Importing operator credentials.

7.1.60 CMSCardRequest/Group/User/Card/AdditionalFields

Used to specify additional job (Xj) fields. Your system must already have been customized to set up these additional fields.

7.1.61 CMSCardRequest/Group/User/CardUpdate

Note: This CardUpdate node is reserved for future use. Do not use. You can use the CMSCardRequest/Group/User/Card/Update node instead.

The CardUpdate element contains details of card update requirements for existing cards.

7.1.62 CMSCardRequest/Group/User/CardUpdate/SerialNumber

Serial Number of the card to be updated.

7.1.63 CMSCardRequest/Group/User/CardUpdate/DeviceType

Device Type of card to be updated (for example, 'Oberthur v3').

7.1.64 CMSCardRequest/Group/User/CardUpdate/CardRequestedBy

The logon name of the person requesting the card update. Used for auditing purposes.

7.1.65 CMSCardRequest/Group/User/CardUpdate/ParametersXML

XML describing the card updates to be performed. Currently supports only UnlockPIN.

7.1.66 CMSCardRequest/Group/User/CardUpdate/ParametersXML/UnlockPIN

Not supported.

7.1.67 CMSCardRequest/Group/User/CardUpdate/PIN

Reserved for future use.

7.1.68 CMSCardRequest/Group/User/Account

Contains details of the user's account.

7.1.69 CMSCardRequest/Group/User/Account/DN

Internal name: DistinguishedName

The DN of the user's account in the LDAP.

7.1.70 CMSCardRequest/Group/User/Account/CN

Internal name: CommonName

7.1.71 CMSCardRequest/Group/User/Account/OU

Internal name: OrganisationalUnit

7.1.72 CMSCardRequest/Group/User/Account/UPN

Internal name: UserPrincipalName

7.1.73 CMSCardRequest/Group/User/Account/SAMAccountName

The SAM Account Name for the user.

7.1.74 CMSCardRequest/Group/User/Account/LogonName

Internal name: LogonName

The user’s name, used to log into MyID. Must be unique.

A LogonName is required for all operations. If no value is supplied, the CMSCardRequest/Group/User/Personal/EmployeeID value is used instead. For new user imports, the EmployeeID is copied to the user's new LogonName record; for actions on existing users, the EmployeeID is used to match against the LogonName.

7.1.75 CMSCardRequest/Group/User/Account/NewLogonName

Note: This feature reserved for future use.

Allows you to specify a new logon name for the user.

7.1.76 CMSCardRequest/Group/User/Account/UniqueID

Maps onto the objectGUID attribute in Active Directory. When MyID synchronizes with the LDAP, it uses this UniqueID to map the users from MyID to the directory.

If your directory does not have an objectGUID attribute, the Distinguished Name for the user is used instead.

7.1.77 CMSCardRequest/Group/User/Account/Roles

Contains details of the MyID roles assigned to the user.

Note: You can set any role for a user using the Lifecycle API – the roles you specify override any role restrictions. Also, the user will not receive any default roles that have been set up for their group; if you want to assign roles, you must include them explicitly. If you do not specify any roles, the user receives the default Cardholder and Password User roles.

7.1.78 CMSCardRequest/Group/User/Account/Roles/Role

Contains details of the role you want to assign the applicant.

7.1.79 CMSCardRequest/Group/User/Account/Roles/Role/Name

Internal name: UserProfile

The name of the role.

7.1.80 CMSCardRequest/Group/User/Account/Roles/Role/Scope

Internal name: Scope

The scope of the role that the applicant is to have. The value must be one of the following:

• None

• Self

• Department

• Division

• All

Note: If you want to remove an existing role from a user's account, set the Scope to None, and the RolesActionOnDuplicate parameter to MergeEmpty.

7.1.81 CMSCardRequest/Group/User/Account/Roles/Role/LogonMechanism

Internal name: LogonMechanism

Not supported. Do not use.

7.1.82 CMSCardRequest/Group/User/Account/EntrustProfile

Specifies an Entrust profile template to use for the applicant. If specified, the applicant is added to Entrust using the template.

7.1.83 CMSCardRequest/Group/User/Account/MaxRequestExpiryDate

Allows you to set the maximum credential expiry date for a person – this allows you to specify the latest expiry date for any device issued to this person. Note that card requests cannot exceed the Lifetime set in the credential profile. Also, the credential profile can override the maximum expiry date for a person using the Ignore User Expiry Date option.

If the Expire Cards at End of Day configuration option is set to Yes, the time portion of the user's maximum credential expiry date is set to 23:59 UTC – the end of the day. If the Expire Cards at End of Day option is set to No, the time portion is set to 00:00 UTC – the start of the day.

If you supply an expiry date in the CardExpiryDate node, it may also cause a check to be performed even when Max Request Expiry Date is not set in the same transaction using the Lifecycle API. See section 7.1.29, CMSCardRequest/Group/User/Card/CardExpiryDate.

Note: Some CAs do not allow control over the time portion of the certificate expiry. When MyID sets the lifetime of the certificate, the date is set as expected, but the time may not match exactly, depending on the certificate authority being used.

This setting affects all future device requests. It does not affect any issued devices or existing requests.

Note: This setting affects device requests made through the MyID Operator Client or the Lifecycle API. Requests made through MyID Desktop do not take this setting into account.

See the Requesting a device for a person section in the MyID Operator Client guide for more information.

7.1.84 CMSCardRequest/Group/User/Account/UserDataApproved

Internal name: UserDataApproved

Contains information on whether card issuance is approved for this applicant. Can be one of the following values:

• YES or 1

• NO or 0

If you set the card profile to have the Require user data to be approved option, you must set this option before the card can be issued. This flag confirms that the data being sent to MyID has passed all the enrollment checks required for card issuance.

Note: The VettingDate defaults to the current date if UserDataApproved is set to YES or 1, and an explicit VettingDate is not provided in the request.

7.1.85 CMSCardRequest/Group/User/Account/VettingDate

Internal name: VettingDate

Contains the date on which the applicant's identity checks were carried out. The format is:

YYYY-MM-DDThh:mm:ss

You can use this field to ensure that the applicant's identity checks are renewed periodically. See the Identity checks section in the Administration Guide for details.

7.1.86 CMSCardRequest/Group/User/Account/UserSID

Allows you to provide the user security identifier (user SID) for a person.

For information on user SIDs, see the Including user security identifiers in certificates section in the Administration Guide.

7.1.87 CMSCardRequest/Group/User/Photo

Contains the applicant's photo.

7.1.88 CMSCardRequest/Group/User/Photo/Encoding

The type of data encoded in the block. This can be one of the following:

• jpg – JPG image data.

• gif – GIF image data.

• png – PNG image data.

• bmp – Windows bitmap image data.

• 378 – INCITS 378 fingerprint data.

• 385 – facial biometrics in ANSI/INCITS 385-2004 format.

For details of importing fingerprints or facial biometrics, contact customer support.

7.1.89 CMSCardRequest/Group/User/Photo/Data

A string of base64-encoded data containing the file to be uploaded.

7.1.90 CMSCardRequest/Group/User/Photo/DateTaken

The date of the data; for example, when the photograph was taken, or when the fingerprints were captured.

This node uses the following format:

yyyy-mm-ddThh:mm:ss.nnn

For example:

2010-01-02T14:23:54.123

7.1.91 CMSCardRequest/Group/User/Photo/Source

Not supported.

7.1.92 CMSCardRequest/Group/User/Photo/None

Instead of providing a photograph, you can remove an existing user photograph and replace it with the noImage.gif default image.

To remove a user photograph, specify _NULL_ in the Photo node; for example:

<Photo>
  <None>_NULL_</None>
<Photo>

Note: The image is removed from the user record, but is not removed from the MyID web server.

7.1.93 CMSCardRequest/Group/User/AdminGroups

An optional node that allows you to specify one or more administrative groups for the user. See the Administration Guide for details of setting up and using administrative groups.

The AdminGroups node contains one or more AdminGroup.

For example:

<AdminGroups>
  <AdminGroup>
    <Name>Group 1</Name>
  </AdminGroup>
</AdminGroups>

or:

<AdminGroups>
  <AdminGroup>
    <Name>Group 1</Name>
  </AdminGroup>
  <AdminGroup>
    <Name>Group 2</Name>
  </AdminGroup>
</AdminGroups>

If the user has existing administrative groups, they are replaced by the specified group or groups. If you specify an empty AdminGroups node, this clears all of the user's administrative groups. If you do not specify an AdminGroups node, the user's administrative groups remain unchanged.

7.1.94 CMSCardRequest/Group/User/AdminGroups/AdminGroup

Specifies an administrative group for the user. You can have multiple AdminGroup nodes in the AdminGroups parent node. An AdminGroup node contains a single Name node.

7.1.95 CMSCardRequest/Group/User/AdminGroups/AdminGroup/Name

Specifies the name of the administrative group for the user.

Note: The group must already exist in the MyID database. If the group does not exist, the import will fail.

7.1.96 CMSCardRequest/Group/User/AdditionalFields

You can import information into additional extended user (Xu) fields using the data import.

7.1.97 CMSCardRequest/Group/User/Actions

Contains actions to carry out for the applicant; for example, to remove or disable the user, or to cancel the user's credentials.

7.1.98 CMSCardRequest/Group/User/Actions/ApplicantAction

Perform an action on the user. If you do not supply an ApplicantAction element, a disabled user will be re-enabled.

The possible actions are:

• Disable – disable the user's account.

• Remove – remove the user from the system.

• CancelDevices – Cancel all the user's credentials.

• CancelDevice – Cancel specific credentials. Specify the cards using the CMSCardRequest/Group/User/Actions/Device element.

• CancelJob – Cancel a specific job. Specify the job using the CMSCardRequest/Group/User/Actions/Job element.

• CancelAllJobs – Cancel all jobs for the specified user.

• UnlockCard – Unlock a card. Specify the card using the CMSCardRequest/Group/User/Actions/Device element.

  Note: This is not currently supported.

• RenewCertificate – renew a certificate. Specify the certificate using CMSCardRequest/Group/User/Actions/CertSerialNumber and CMSCardRequest/Group/User/Actions/CertPolicyName.

7.1.99 CMSCardRequest/Group/User/Actions/CertSerialNumber

Used in conjunction with CMSCardRequest/Group/User/Actions/CertPolicyName to specify a certificate to renew.

7.1.100 CMSCardRequest/Group/User/Actions/CertPolicyName

Used in conjunction with CMSCardRequest/Group/User/Actions/CertSerialNumber to specify a certificate to renew.

7.1.101 CMSCardRequest/Group/User/Actions/StatusMappingID

The action to apply to the user. This should be an ID that matches an entry in the StatusMappings table. It controls how certificates are revoked.

7.1.102 CMSCardRequest/Group/User/Actions/RevocationComment

A free text description that is stored against revoked certificates in the database.

7.1.103 CMSCardRequest/Group/User/Actions/RevocationDelay

Used to specify a delay in hours for the certificate revocation requests.

When you create a request to cancel a device, its certificates are not canceled immediately, but are canceled after the specified number of hours.

If the credential profile is configured so that it must be validated before cancellation, the certificates are not canceled until the specified number of hours after the cancellation request is approved.

7.1.104 CMSCardRequest/Group/User/Actions/Device

Specifies the card to cancel when you have selected CancelDevice for the ApplicantAction, or the card to unlock when you have selected UnlockCard for the ApplicantAction. (Note: UnlockCard is not currently supported.)

Contains at least one DeviceIdentifier element – you can cancel multiple cards in a single request.

7.1.105 CMSCardRequest/Group/User/Actions/Device/DeviceIdentifier

Specifies the credential to be canceled or unlocked.

7.1.106 CMSCardRequest/Group/User/Actions/Device/DeviceIdentifier/ SerialNumber

The serial number of the credential.

7.1.107 CMSCardRequest/Group/User/Actions/Device/DeviceIdentifier/ SerialNumberField

The name of the field in which to look for the serial number. The field can be any field present in the vDevices view; for example, SerialNumber for the standard serial number or HIDSerialNumber for the HID serial number.

If you do not include a SerialNumberField node, MyID will use a default value of SerialNumber.

7.1.108 CMSCardRequest/Group/User/Actions/Device/ProcessStatus

Used to specify the process status to be used for the credential being canceled.

You can use the following status codes, as listed in the DeviceProcessStatuses table in the database.

You can customize your system with additional disposal statuses; for information on the configuration required, contact customer support quoting reference SUP-387.

7.1.109 CMSCardRequest/Group/User/Actions/RequestedBy

Used to specify the MyID logon name of the Initiator for any jobs created by the import process. If you do not specify a value here, the Initiator is set to ImportProcessor.

You can use the Initiator tab in the Job Management workflow to search for jobs created by specific users.

7.1.110 CMSCardRequest/Group/User/Actions/Job

Contains a the ID of a job to cancel. Used in conjunction with an ApplicantAction of CancelJob.

7.1.111 CMSCardRequest/Group/User/Actions/Filters

The feature to filter job cancellations using criteria is now "End of Life". The Filters node remains in the Lifecycle API schema, but cannot be used.

See section 3.10.3, Filtering job cancellations for more information.